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SYSTEM AND METHOD FOR PROGRAMMING USING 
INDEPENDENT AND REUSABLE SOFTWARE UNITS 
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BACKGROUND OF THE INVENTION 



Hie present invention relates generally to the reuse of software code 
within \he area of objected-oriented programming languages, and more 
specifically to a system constructed in accordance with a programming language 
where softwarte reusability is achieved by the use of reusable software units 
{or connectons)\ defined modularly and hierarchically, and by the remotion all 
10 absolute addresses from connectons. 

Software reusability is an attribute of software that facilitates its 
incorporation into new application programs. Software reusability has become 
a timely topic because of economic reasons, i.e., projects that reuse code are 
cheaper and take less time to complete. During the early days of computer 
15 programming, the most successful examples of software reuse were subroutine 
libraries. More recently, Software Design Patterns are considered to be a 
promising reuse technology. 

I. Object Oriented Programming 

A programming language is object oriented if it supports objects as a 
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(LanguagX feature, and objects belong to classes that can be incrementally 
modified through inheritance (i.e., Simula, Smalltalk, C++, Eiffel and Ada) . 
The essenceNof object oriented programming is the hiding or encapsulation of 
the "inner" sfcate of entities and the specification of interactive properties 
25 of entities by\an interface of operations (the events in which they may 
participate . 

Object-oriented languages encapsulate data as well as sequences of 
actions, providing a stronger encapsulation mechanism than procedures, and 
consequently, a more powerful modeling tool. The state of objects is to serve 
30 as a repository of data (current system state) . Object-oriented programming is 
a modeling paradigm that represents objects of the real world by collections 
of interacting objects of a programming system. 
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Objects in programming languages are collections of operations, which 
share a state. The operations determine the messages (calls) to which the 
object can respond, while the shared state is hidden from the outside world 
and accessible only by object operation. Variables representing the internal 
5 state of an object are called instance variables, and object operations are 
called methods. The collection of methods of an object determines its 
interface and behavior. 

Classes serve as templates from which objects may be created. Different 
flavors exist, and, for example, in Smalltalk, classes are also objects, and 

10 exist as such even if no objects are created. Inheritance is a mechanism for 
sharing code and behavior, allowing the reuse of behavior of a class in the 
definition of new classes. Subclasses of a class inherit the operations of 
their parent class and may add new operations and new instance variables . 
Polymorphism, the ability to invoke different code to respond to the same 

15 . message name, is also considered as an important characteristic of object- 
oriented languages. 

However, even in the more regimented atmosphere of object oriented code 
(e.g., Smalltalk), there is still no accepted methodology to create 
repositories of software, which would facilitate software reuse. For that 

20 matter, other technological fields do not suffer from the software reuse 
problem. For example, repositories of hardware for future use are known. For 
that matter, the problem with objects, as distinguished from integrated 
circuits (ICs) is that 1) contemporary object components do not behave 
independently of each other; and 2) objects cannot be built in a hierarchical 

25 and modular form. The reason for the first problem is that object technology 
does not provide a transparent mechanism for communication among objects, as 
compared to ICs, which are independent from each other. The reason for the 
second problem is that in traditional object oriented languages, one cannot 
create new objects by composition of other objects, severely limiting the 

30 ability to build large hierarchical systems. 

II. Software Reuse 

Perhaps one of the most successful paradigms for software reuse is the 
model -view-controller (MVC) concept introduced by Smalltalk language, that has 
35 influenced the JavaBeans component model, see A. DeSoto. Using the Beans 
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Development Kit 1.0. JavaSoft, 1997. The dependence mechanism provides some 
support for reuse. An object can have a collection of dependents, and when an 
object changes its state, it can send itself an update message; this message 
then sends an update message to all the dependents. Thus, an object can be 
5 built without any knowledge of its peers. The dependence mechanism permits the 
reuse of objects in different contexts. Also, because the dependent list can 
be changed in run- time, this method provides support for managing adaptive 
behavior . 

The dependence mechanism has, however, several inconveniences. First, 
10 all the dependents must have an update method, and second, when an update 
message is issued, all the dependents receive the message. The message 
broadcast can become very inefficient, and because the update message is so 
general, all the parameters must be sent as arguments, making it very 
difficult to introduce new types of objects. 
15 Adapters provide a mechanism for code reuse, and were first implemented 

"ill in VisualWorks, see E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design 

Vii. Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. 

Adapters attempt to solve the problem of connecting objects with different 
'i^l interfaces. In this framework, when objects with incompatible interfaces need 

20 to communicate, an adapter is created to transform message calls of one object 

Sri 

in_message calls the second object can understand. 

pioes, through their simplicity, were one of the first constructs to 
v provide software reuse. Pipes used in the UNIX operating systems provide an 
J* interesting mechanism for software reuse. Programs in the operating system can 

^ 25 behave independently sending their outputs through a pipe to another program. 

Pipes have severe limitations, however. They can pass only unstructured data 
like characters, and t^iey provide only a one -direction mechanism. 

Producing software "ICs M has long been advised as a solution to software 
reuse, B.J. Cox. Object Oriented Programming: An Evolutionary Approach. 
30 Addison-Wesley, 1987. Very interesting applications of this concept can be 
found in, S. Koshafian and R. Abnous. Object Orientation: Concepts, Languages, 
Databases and User Interfaces. John Wiley, 1989, where a hardware application 
is described, and recently in, B.P. Zeigler. Objects and Systems: Principled 
Design with Implementation in C++ and Java. Springer Verlag, 1997. The 
35 construction of hierarchical and modular objects is known to be achievable by 
replacing object absolute addresses by parameters that are only assigned at 
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run time when the object is created. This permits the use of the same object 
in different contexts (i.e., applications). While this approach is beneficial, 
it still includes the inherent drawback that the name of the message sent to 
the outside of the object is still hard-coded. 
5 Patterns were thought to be a promising solution to software reuse, and 

were created to explore the limits of object oriented programming, see E. 
Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of 
Reusable Object-Oriented Software. Addison-Wesley, 1995. Patterns categorize and 
exemplify how a set of classes may be used to construct a certain system. 

10 Patterns constitute a case by case reuse, but are limited. Patterns do not 
support the construction of independent units of software, but rather the 
programmer must incorporate the pattern design in the implementation. A good 
overview of software reuse techniques can be found in, J. Sametinger. Software 
Engineering with Reusable Components. Springer Verlag, 1997, and C. 

15 Szyperski. Component Software: Beyond Object-Oriented Programming. Addison- 
Wesley, 1998. 

III. Why Objects Fail 

20 Objects have been recognized as the solution to software low 

productivity. Object reuse by means of inheritance or by the use of Abstract 
Data Types seemed to be promising. However, those skilled in the arts soon 
realized that these promises were not fulfilled by the new technology. Reuse 
of low level objects has shown to be much easier than reuse of an overall 

25 design. 

Furthermore, the object solution seems not to scale. Simple objects like 
lists and dictionaries can easily be reused but complex applications cannot. 
For example, reusing a graphical editor as a whole is more complex than 
reusing the constituting classes when they are viewed as independent units. 

30 The problem becomes more evident as the size and complexity of the application 
begins to grow. This difficulty has been assigned to the lack of comments in 
the code, and also to the low commitment to reuse by software engineers. 
Although some part of this may be true, we believe that the problem only 
becomes marginally smaller by using informal techniques. We are convinced that 

35 the object methodology is responsible for the crises, and consequently, a 
paradigm shift towards more powerful concepts is needed. 
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Difficulty also arises from the fact that higher level programming 
languages, from their very beginnings, are based on the limitations of the 
machines in which they were designated to operate, i.e., they try to make 
efficient use of hardware while improving human readability. The generalized 
5 use of pointers and subroutine calls is symptomatic of a machine -oriented 
design. Although objects (in object oriented programming languages) have 
introduced the concept and use of "state" , object messages are still not very 
different from routine or procedure calls and use. 

Developed in a different science, "General Systems Theory", M.D. 

10 Mesarovic and Y. Takahara. General Systems Theory: A Mathematical Foundation. 
Academic Press, 1975 and B.P. Zeigler. Theory of Modeling and Simulation. 
John Wiley, 1976, the concept of "system", appears to provide a better 
abstraction than objects by providing modular and hierarchical description and 
offering the concept of polymorphism. Systems, however, are still unable to 

15 provide a basis for software reusability. The implementation of system 
concepts is contrary to the design of "quick and dirty" programming languages, 
required during the time that computers were quite slow. In addition, due to 
the contrast between the timed, asynchronous and pull nature of systems, and 
the non- timed, synchronous and push nature of most programming languages, 

20 adapting systems concepts to programming languages is a substantial problem. 

IV. Object Axioms 

In almost every language a routine, a function, or a message call has 
one of the following formats: 
25 [variable :=] object message [arguments] . (1) 
[variable :=] self message [arguments] . (2) 

Brackets mean that the term is optional. Without loss of generality, we use 
the Smalltalk convention for message calls. In non-object oriented languages, 
what is termed as an "object" is usually sent as an argument to a routine, 

30 that have been renamed by message in the "object paradigm" (of object oriented 
programming languages) . 

Statement 2 poses no problem for reuse for it just assumes that an 
object knows its own details. However, Statement 1, in spite of its simplicity 
and its apparent inof f ensiveness, retains all the four features that destroy 

35 any serious attempt to software reuse, no matter how much effort is employed. 
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These 4 features (the group of four, or G4 for short) kill any chances of 
producing real software ICs. This G4 assumption can be described by the 
following four axioms: 

I) Existence of the receiver. Statement 1 assumes that the receiver 

5 object does exist. 

II) Uniqueness of the receiver. Statement 1 assumes that the message is 
sent to just one object. 

III) Knowledge of the receiver. Statement 1 assumes that the object 
address is known. 

10 IV) Knowledge of the message. Statement 1 assumes that the method 

invoked in the receiver object is known. 

This is too much for just one simple assignment, and these assumptions 
have destroyed any chance of conventional object reuse. Hence, these 
underlying 4 axioms prove to be deadly to software reuse in any of today's 

15 paradigms. While several software paradigms have reduced some of these 
constraints, no conventional systems are known to exist that have reduced them 
all. Although these axioms are evident, their limitations to software reuse 
seem never to have been fully described and exploited. 

More particularly, Axiom I states that if an object must communicate 

20 with another object, this other object must exist. This assumption, which 
seems to be a universal rule, is fallacious. A software entity must work 
without any assumption about its neighbors, even about their existence, if it 
is to be able to operate independently. Axiom II states that objects 
communicate on a one-to-one basis. The same comments set forth with respect to 

25 axiom I can be applied here. 

Axiom III assumes that the object absolute address is known. Absolute 
address is another factor that makes reuse very difficult. Objects that have 
addresses hard-coded by no means can be used in different contexts. To reuse 
objects that satisfy this axiom, it is necessary to replace absolute addresses 

30 by new ones, and then recompile the system again. Because addresses are 
scattered through the code, these changes are virtually impossible in complex 
systems . 

Axiom IV is where machine oriented language design is more visible and 
where it makes more damage. Deciding the name of the message to send to an 
35 object is always fixed in programming languages. 



-6- 



eg\f : \1371\13137\SPEC\13137 . JFV 



I1CLVC I 

mo 7 



The Smalltalk dependence mechanism was probably the first successful 
attempt to remove axioms I and II. The reader should note that the dependence 
mechanism might be described as a relationship between objects where one 
object can receive information about changes made in another object. In this 
framework update messages are sent to a list of dependents , and this list can 
have zero or more elements. 

Loms III and IV have been partially removed by the use of adapters. 
Instead oY sending messages directly to an object, messages are sent to an 
int ermedi at e\ object known as the adapter that converts one object interface to 
10 another. Facade systems based on graphical systems give the false impression 
that axioms IIl\nd IV have been removed. However, the underlying mechanism is 
so complex that thte best that can be expected is that the components existing 
in the library are enough to build an application, otherwise lots of difficult 
tricks must be mastered to complete the programming task Error! Reference 
15 source not found.] . 

d 

Statements 1 and 2 also assume an underlying synchronous design. In most 
j'jl of the programming languages the execution control waits until the call of 

]:: statement 1 terminates before executing the next statement. In asynchronous 

ip programming languages, usually running multiple threads of control, the 

^ 20 execution of statements 1 does not need to terminate before the control of 

ihl 

]~~ execution is given to the next statement. Some programming languages provide 

U a mixture of these 2 characteristics, and the programmer can choose what calls 

f ~* are synchronous and what call are asynchronous. However, synchronous and 

asynchronous characteristics are orthogonal to the problem of software reuse. 

■ 3 25 OBJECTS AND SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to provide an 
application written in connecton- oriented code by which very large systems may 
be constructed in accordance with modular and hierarchical software building, 
which overcomes the shortcomings of the prior art . 
30 It is another object of the invention to provide a scalable mechanism, 

which completely isolates connectons (reusable software units) from their 
peers . 

It is still another object of the invention to provide a mechanism where 
the G4 assumptions discussed above are removed. 
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It is yet another object of this invention to provide simple and sound 
mechanisms with only a few, but powerful, concepts so they can be easily 
mastered and are easy to use. The provided solution must scale, that is, not 
only huge software projects would benefit from it, but also any and every 
trivial piece of software could be designed for reuse if necessary. 

V. Basic Connections 

To that end, the present invention with its concept of connectons was 
designed to provide these solutions. Connectons are based on the concept of 
General Dynamic Structure System, see F.J. Barros, "Formalisms for Dynamic 
Structure Systems," ACM Transactions on Modeling and Computer Simulation, Vol. 
7, No. 4, pp. 501-515, 1997. 

A connecton communicates with the outside world only by gates. Gates are 

thus the only access points to connectons. Object technology also claims 
something similar. In fact object technology provides a clear mechanism for an 
object to be accessed. However, the dual mechanism to access other objects 
from within an object was forgotten. One explanation may account for this 
fact. Invoking a message is just a jump to some specific memory location, a 
legacy from machine code and machine architecture. Sending a message to an 
unknown or possibly non-existing object with an unknown interface, that is, 
removing the G4 axioms, would seem magic. 

Gates, as mentioned, are the only way to interact with a connecton, and 
by interaction we mean both input and output interactions. This type of 
interaction, providing both input and output separation from the outside, 
offers a powerful paradigm to build really reusable software. 

The kernel of software reuse as provided by connectons is the pseudo 
variable out. This variable is responsible for handling all the output 
interaction of a connecton and its meaning can only be accessed at run-time. 
This concept provides a definition of each connecton absolutely independent 
from other connectons. The variable out can represent none, one or many 
connectons, and represents an abstraction of the outside world. Only by 
itself, the out concept would be of little use if we could not discriminate 
the .access to the outside world. This discrimination is achieved by the 
concept of gate. A gate can be defined as a selector or a parameter of 
connecton interaction. Gates provides the fine grain discrimination that lacks 
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the Smalltalk dependence mechanism. With the out and gate constructs we have 
removed the first 3 axioms of G4 . 

To remove Axiom 4 we introduce the concept of channel. A channel, or 
link, is a bi-directional connection between two gates. An assignment, the 
5 most common way of interaction, is a two-sided communication mechanism. The 
sender connecton issues a message with possibly several parameters, and the 
receiver, using the same communication channel, sends a result. 
^-)^>0 ^^"7 Systems {within the art of System's Theory) were designed to represent 
asynchronous communications, like those found in simulation frameworks Error 1 
10 Reference source not found.], and thus systems have only been provided with a 
one way communrtation mechanism. This simple fact prevents systems theory from 
being used as a general framework for programming. Although in principle, a 
synchronous system\an be represented by an equivalent asynchronous system, 
this transformation would lead to cumbersome specifications, because all 
15 synchronous communications should be represented by two one-way links, thus 
doubling the interface of any synchronous system. 

VI. General Description of the Invention 

In one embodiment, the invention comprises a programming implementation 
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20 for use with an object oriented programming language which supports 
delegation, the implementation providing for reusable software units built in 
a hierarchical and modular form is disclosed herein as one embodiment of the 
h; invention. The implementation includes a repository of the reusable software 

units, where each are arranged to behave independently, communicate 
25 transparently, and facilitate creation of new reusable software units. 

The reusable software units are arranged to display a scalable mechanism 
to thoroughly isolate each said reusable unit from its peers, and to 
facilitate reuse of an overall software system design constructed with said 
reusable software units. The reusable software units communicate to the 
30 outside world by use of both input and output gates, which are the only means 
for communicating with said reusable software units. The reusable software 
units are arranged to further include a pseudo variable out, that is only 
meaningful when accessed at run-time. This variable abstracts the outside 
world of each connecton and its meaning depends on what reusable software 
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units are linked to the connecton at the moment of code execution, that is, at 
run time. 

The reusable software units are arranged in an interconnection via bi- 
directional channels, do not include absolute addresses and are dynamically 
5 configurable. Moreover, each connecton (software unit) , is be described by a 
model M given by 

M - (inGates, {inSign g } , {a g } , Q, q Q , outGates , {outSign gt } , {outFunction gt } ) 
where inGates is the set of input gates, outGates is the set of output gates, 
a g is an action for every g in inGates, Q is the set of states, g 0 is the 

10 initial state, inSign gt is the input -to- output signature of every gate gt in 
outGates, outSign gt is the output -to- input signature of every gate gt in 
outGates, and outf"unction ?t is the output function of every gate gt in 
outGates. An input signature is a 2 -tuple containing the range sets of 
incoming and outgoing parameters, and an output signature is a 2-tuple 

15 containing the range sets of outgoing and incoming parameters. 

A plurality of connectons may be combined to construct a connecton 
network E (or connecton ensemble) , defined by 

E = (inGates, {inSign g } , s,M £ , outGates, {outSign gt } , {out Function^} ) 
where s, with model M £ is the ensemble executive a special model that keeps the 

20 ensemble structure. The ensemble executive includes a structure function 
<7: Q -» I* that maps executive states to a structure, where each E e I* is 
equal to ( C, {m c } , L, E) , where C is the set of connectons that belong to the 
ensemble, M c is the definition of every connecton c belonging to set C, L is 
a set of channels, that represent the interactions among connectons. E is the 

25 order function that describes the order actions will be invoked. 

In the implementation, structural inheritance is utilized to build new 
connectons from existing connectons, and traditional objects may be utilized 
as connectons having no output gates. Changes in the network structure are 
achieved by changing the executive state. The structure depends on executive 

30 state, being the map made by function a. 

BRIEF DESCRIPTION OF THE DRAWING FIGURES 

Fig. 1 is schematic diagram depicting the interconnection of several 
connectons of this invention; 
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Fig. 2 is a schematic diagram depicting an OR connecton, implemented in 
accordance with the principles disclosed herein; 

Fig. 3 is a schematic diagram depicting a bank account implementation, 
including a client connecton, implemented in accordance with the principles 
5 disclosed herein; 

Fig. 4 is a schematic diagram depicting an ORTest connecton ensemble 
implemented in accordance with the principles disclosed herein; 

Fig. 5 is a schematic diagram depicting a factorial connecton, 
implemented in accordance with the principles disclosed herein; 
10 Fig. 6 is a schematic diagram depicting the basic Node connecton, used 

to build an Erastosthenes sieve of prime numbers in accordance with the 
principles disclosed herein; 

Fig. 7 is a schematic diagram of an Erastosthenes sieve initial 
configuration arranged in accordance with the principles disclosed herein; 
15 Fig. 8 is a schematic diagram of a pipeline shown after receiving a 

sequence <2,3,4,5,6>, including nodes N2, N3, and N5 for primes numbers 2, 3 
and 5, respectively; 

Fig. 9 is a schematic diagram of a connecton kernel arranged in 
accordance with the principles disclosed herein; 
20 Fig. 10 is a table that represents a partial view of the Desmos 

hierarchy, the implementation of the principles of the invention herein; 

Fig. 11 is a schematic diagram depicting a 4 -input OR gate class 
(network) comprising 3 basic 2 -input OR gate connectons; 

Fig. 12 is a representation of the code definition of the OR4 class 
25 depicted in Fig. 11; 

Fig. 13 is a schematic diagram of a NOR4 class derived from the OR4 
class depicted in Fig. 11; 

Fig. 14 is a representation of the code definition of the N0R4 class 
depicted in Fig. 13; 

30 Fig. 15 is a schematic representation of a speed control system (class), 

implemented to display the speed of a car; 

Fig. 16 is a schematic representation of a speed control system (class) 
of Fig. 15, further including two graphical widgets that display the value and 
velocity; and 

35 Fig. 17 is a schematic representation of a chain of responsibility 

connecton implemented in accordance with the principles set forth herein. 
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DETAILED DESCRIPTION OF THE INVENTION 



VII. Connectons Implemented Herein 

\ A possible connection among three connectons A, B and C of the present 
invention is represented in Fig. 1. Connecton A is linked to connecton B 
5 through a channel (link) starting at gate go of connecton A, and ending at 
gate scart of connecton B. Connecton A is linked to connecton C through a 
channel f\pm gate go to gate begin. Connecton A is linked to connectons B and 
C. However, >t here could be more linked connectons. Connecton A could be linked 
just to one (connecton, or it could be linked to no connecton at all. A 
10 channel, or link, makes the interface between two different gates, thus a 
connecton only nefeds to know its own output gates. The name of the gates of 
outside connectons \ that represent message names, are entirely handled by the 
channel support, permitting removal of Axiom 4. It may look strange that 
although channels repi^sent a bi-directional communication link, they are 
13- 15 represented by an arrow\ The arrow represents the direction of the request, 
the requested information Vravels is in the opposite direction and thus is not 
1 1 J explicitly represented. \ 

&5 As mentioned above, every connecton has a variable (pseudo variable) 

called out that provides the communication with the outside connectons. In the 
20 example of Fig. 1, the interaction between connecton A and connectons B and C 
;! { . is achieved by the statement out go. This meaning should be clear, a message 

j£j called go is sent to the outside world. Its effect depends on the connectons 

^ currently linked from that gate. In this example, connectons B and C invoke 

their own methods start and begin, respectively. In a general case, all the 
Q) 25 connectons linked to gate go invoke some method prescribed by their input 
gates. 

VIII. Connecton Definition 

Each connecton has its own description referred to as the connecton 
30 model. Given a connecton M, its model is described by 

M = (inGates, {±nSign g } , {a g } ,Q,q Q , outGates, {outSign gt } , {outFunction gt }) 
where inGates is the set of connecton input gates, outGates is the set of 
connecton output gates, a g is an action for every gate g belonging to set 
inGates, Q is the set of connecton states, q 0 is the connecton initial state, 
35 inSign g is the input -output signature of every gate g in inGates, outSign gt is 
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the output -to- input signature of every gate gt in outGates, and outFunction gc 
is the output function of every gate gt in outGates. 

An input signature is a 2 -tuple containing the range set of the incoming 
parameters and the range set of outgoing parameters. For example, if input 
gate g receives real values R, and responds by sending integer values I, then 
is input signature is given by 
inSign g = (R,I) 

An output signature is a 2 -tuple containing the range set of the outgoing 
parameters and the range set of incoming parameters. 
10 ^/^^T^he function a g on input gate g of signature (I g ,O g ) is expressed by 
Q x X g -> Q x O g 

An action correspond to a method in the object paradigm. An action a g receives 
input valuesXfrom (Q x I g ) , produces a change in the connecton state, and 
returns a valueXfrom O g . As a side effect, an action on a connecton can trigger 
15 other actions onVthe connectons linked to it. An action can trigger state 
changes in other connectons, but these changes are made by actions defined on 
those connectons, soVtiodularity is not jeopardized. We do not attempt to make 
a formal definition o£ this side effect for it will be clear in the next 
examples . 

20 Output functions convert the set of values received by an output gate. 

These functions are very useful when several channels are linked to an output 
gate, and in general, to convert values without creating special connectons. 
For example in a bank application (Fig. 3), if gate deposit: is linked to a 
set of bank accounts, the following action defined in the Desmos system, a 

25 Smalltalk implementation of the connecton paradigm disclosed herein, 
interrogates the several accounts for their money 
value 

A total := out deposit: myself "myself represents the client connecton" 

The value of variable total is the result of applying the output function over 
30 the set of values returned by the connectons linked from gate deposit: . If we 

are interested in the total amount we need to define an output function that 

sums the values from all the accounts represented in the valueList array 

returned to gate deposit:. This function is defined by 

outputFunction deposlt , (valueList) 
35 value := 0. 
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for i := 1 to (valueList size) do 
value := value + valueList[i] 

endFor 

return (value) 

5 

In the current implementation, if no output function is defined, the 
following default function, named (p, is used 
defaultOutputFunction{ valueList) 
if (valueList size = 0} 
10 return (nil) 

else 

sz := valueList size 
return ( val ueLi s t [ sz] ) 

endlf 



15 



20 



This function just returns nil if no channel links to a gate and returns 
the last value from the input list, if there is at least one channel. This 
behavior seems to cover the most common situations and it seems to be 
preferable to just return a list of values. 

IX. The OR Connecton 



Fig. 2 represents an OR connecton. This connecton has one input gate 
called ou\. and two output gates called inl and in2 . The input gates 
corresponds \o actions (methods) defined in the connecton. The output gates 
25 correspond to request for actions (message calls) that a connecton can send to 
its peers. The Ok connecton has no internal state and computes the logical Or 
of the values present at output gates inl and in2. This connecton is described 
by 

OR = ({out}, { (0,k},{a wt },| <±nl # ±n2}> , {0,B) , (0,B) }) 
30 where B = {0,1} is the seCvof Boolean values, and 0 represents that no value 
is needed. The output function is omitted for no adaptation is needed. 

When the OR element receives a message on gate out, it asks for two 
values through gates inl and in2 and returns the logical Or of these two 
values . 
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We describe now the implementation of this connecton in the Desmos 

system, a Smalltalk implementation of the Connecton paradigm. The OR connecton 

has two actions (methods) : inOates and outQates, that define, respectively, 

input and output gates. 

5 inGates 

A super inGates add: #out. 
outGates 

A super outGates add: #inl; add: #in2. 

10 The code for action out that computes the logical Or is given by 

out 

la b| 

a := out inl. "Obtain the value at gate inl" 
b := out in2. "Obtain the value at gate in2" 
15 A a|b "Returns the logical Or" 

As mentioned before, the access to outside connectons is achieved by the 
use of the pseudo- variable out. The name of the output gates provides just an 
alias to access the gates of other connectons. There is also no need for a 
20 connecton to know the names of other connecton actions, i.e., their input 
gates. The pseudo variable out and the gate concept permit to define the OR 
connecton without any reference to other connectons. 

X. Bank Account Example 

We\^describe now, in more detail, the bank account example used in a 
• :! " : ' previous section. Fig. 3 represents the client connecton that receives in the 

output gate deposit: the values deposited in bank accounts Bl, B2 and B3 . The 
. client is described by 
S3 C = ({value}, {C^,R) }/ {3^^}, {deposit: },{ (Names, R) }, {ouputFunctiondepo.it;}) 

30 where Names is the\et of client names (not defined here for simplicity) . 

Output gates and the respective output function are defined by the 
method outGates given by 



• try' 

Pi 



outGates 

^super outGates add: #deposit: function: [:x|x inject: 0 into:[:a :b| a+b] ] 



3 S 

feate\ deposit : is attached to an output function described in Smalltalk by the 
block\ [:x| x inject: 0 into: [:a :b| a + b] ] . This block converts the input 
list inCo a single value (the sum of values in the list) . This function also 
provides me default value 0 if no channel is connected to gate deposit: . The 
4 0 action associated with input gate value is defined by 
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"out deposit: myself 



r self represents the bank customer. 



XI. Network of Connections 

A connecton network, or connecton ensemble, is a complex connecton built 
by the composition of other connectons. It is defined by 

E = (inGates, {inSign g } , s,M E , outGates, {outSign gt } , {outFunction fft } ) . 

10 This definition introduces the ensemble (network) executive €, and its model M ei 
a special connecton that maintains the ensemble structure. The executive keeps 
a list of the connectons that compose the ensemble and also keeps a list of 
the channels existing among connectons. This information is not static, and 
can be changed by executive actions . The executive is defined by 

15 M £ = {inGates, {inSign g } t {a g } ,a t r f Q,q ot outGates, {outS±gn gt } , {outFunction gt }) 

A special function is defined in the executive that maps the executive state 
into an ensemble structure. The structure function is expressed by 



where C is the set of connectons that belong to the ensemble, M c is the model 
(definition) of each connecton c belonging to set C, Lisa set of channels 
and S is the order function. 

A channel is a 3-tuple defined by ((i.gj, (j,9j) , (dF,rF)) , where i is the 

25 name of the source connecton, g t is a gate of the i connecton, j is the 
receiver connecton, g^ is a gate of j, dF is the channel direct filter, and rF 
is the channel reverse filter. When absent, dF and rF are assumed to be the 
identity function. The identity function IDY, is a function that just yields 
the input parameter. It is given by IDY(x) = x. 

30 When value a x is sent from gate g i to gate g^ by a channel with filter 

(dF, rF), connecton j performs j a gj dF(x) and returns the value rF{j dF(x) ) , 
being the action executed only once. In the previous statements we assume the 
Smalltalk syntax for message calls given by: object message arguments, where 
the arguments are omitted if the message needs no parameters . 



20 



Each structure 2 in I* is given by 
I = (C, {M c } , L r H) 
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Filters transform both the values sent and received by a connecton. For 
example if a connecton works with values in Miles and needs to communicate 
with connectons operating in Km, then filtering capabilities provide an 
elegant solution to make this conversion without the creation of additional 
5 connectons to make the adaptation. In this case the direct filter would be 
given by df(x) = 1.65x, and the reverse filter would be given by rF(x) = x/l.65 
to make the conversions between Miles and Km. 

2: L*->L + is the order function, where L + is the set of all sets of links 
(excluding the empty sequence) . 
10 The order function establishes the order of the outside calls when 

several channels are linked from the same output gate. For simplicity, we omit 
reference to this function for the remainder herein by assuming a non- 
deterministic order. 

The initial structure of the ensemble I 0 is given by 2 0 = cr(g 0 ) , where g 0 
15 is the executive initial state. 



XII. Random Logic Application 

J^O hs^f 4 represents an ensemble with three connectons and the executive. 

^The/ enserttole is defined by 
20 \ JWst = (InGates, {inSign g } ,£,M £ ) 



where 

inGates \ { inl : , in2 : , out } 
inSign = (Vb,0) , (B,0) , <0,B) } 

I s A^ e executive has just one state that corresponds to a single ensemble 
structure defined by 

<j(q^ = (C, {M c },l0 

where 

C = {Hl,\l2,OR} 
30 {M c } = {^W^l 

L = { ( (ORTesVinl:) , (HI, value: ) ) , ( (ORTest , in2 : ) , (H2, value:) ) , 
( (OR, inl) , (Hl\alue) ) , (OR, in2) , (H2, value) ) , ( (ORTest, out) , (OR,out) ) } 
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The Nf ollowing example explains how connections may be used within a 
program. Fisst, we define a "holder" connecton. A holder connection has two 
input gates: \) value: that sets a state variable to a given value storing 
this value, 2) Vr alue that returns the stored value. The connecton ensemble, 
5 represented in Rig. 4, is composed of one OR connecton, linked to holder 
connectons, HI anc\H2. The ensemble has two input gates inl : and in2: to set 
logical values, andNthe gate out to communicate the result. 

The ensemble connecton is called ORTest and includes the executive 
connecton, ORTest £t that holds the overall structure. The structure of any 
10 ensemble is defined by the method connectonStructure that every ensemble class 
must define. The variable Network is an alias for the actual network 
(ensemble) . The ORTest connecton network is defined in the Desmos system by 

c onnec tonS t r uc tur e 

|str| 

15 str : = super connectonStructure. 

"Obtain the structure of the parent class" 

str addConnecton : #H1 class: Holder. "Adds Holder HI" 

str addConnecton: #H2 class: Holder. "Adds Holder H2" 

str addConnecton: #OR class: OR. "Add an OR connecton" 

20 "Links the Network to HI" 

str link: Network gate: #inl : to: #H1 gate: #value:. 
"Links the Network to H2" 

str link: Network gate: #in2: to: #H2 gate: #value:. 
str link: #OR gate: #inl: to: #H1 gate: #value. "Links OR to HI" 
25 str link: #OR gate: #in2: to: #H2 gate: #value. "Links OR to H2" 

A str. 

To test this network, we use the method orTest that is defined in Desmos by 

orTest 

30 . |orN value | 

orN := ORTest new. "Creates a ORTest Network" 

orN inl: true. "Sets the inl: gate value" 

orN in2: false. "Sets the in2 : gate value" 

value := orN out. "Computes the Or value" 
35 Transcript nextPutAll: value asString; cr. "Prints the value" 

The message new sent to the Connecton class ORTest creates a new 
connecton with the structure defined in its connectonStructure class method. 
As gate names correspond to method names, standard object messages can be used 
40 to communicate with connectons. 
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XIII. Scaling 

/ \ Modularity and hierarchy connect on building can be used as a paradigm to 
represent very complex systems. Fig. 5 illustrates how "small" connecton 
granularity may be. We model the factorial function by a connecton. The 
recursive definition of factorial is given by 
fact (n) 

if n = N 



10 

The connecton representation of this function is given by 

fact: n 

n = 0 if True: ,\ 
15 A n * (out out:(n-l)J\ 

In Fig. 5, the factorial executive was omitted for simplification. While 
this example is merely illustrative, it shows that the connecton paradigm may 
be used for representing arbitrarily small components . 



20 



XIV. Changes In Connecton Structure 

Fig. 6 shows the Node connecton that serves as a basis to build the 



Erastokthenes sieve of prime numbers. Fig. 7 represents the sieve initial 
configuration. Each connecton in Fig. 8 holds a different prime number named 
25 id. Each connecton tests if it can divide an incoming number by id. If the 
node can divide the number then the number is discarded for it is not prime. 
If the numberNcannot be divided by id, the node sends the number to other 
connectons, which performs the same test, and so on. If the number cannot be 
divided by the las\ connecton in the chain, the element sends a signal to the 
30 executive to create\a new node to handle the found prime. This action is 
defined by 
in: aNumber 

(aNumber \\ id = 0) if^rue: [ A nil] . "Tests if aNumber is divisible by id tt 
A out out: aNumber "stends the number to the next node for checking" 



35 



In this simplified and non optimized version of the sieve each node can 
only give a negative answer. Saying that a number is prime involves the 
cooperation of all the nodes. A number is considered to be prime no node in 
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XV. The Desmos System 

smos, the embodiment of the invention implementing the connecton 




ill 
j-lf 

'•Li- 
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paradigm \s disclosed herein is built on the Smalltalk language, see Smalltalk 
MT User's ^uide. Object Connect, 1995. Smalltalk was used for simplicity of 
the delegation implementation. However, the Desmos implementation of the 
connecton paraaigm of this invention is not limited to Smalltalk, but to any 
OOP language thatN^an use delegation and reflection. The reader should note 
that those skilled inVhe art will understand how and which changes to make in 
conventional compilers\interpreters of existing languages in order to 
implement an embodiment of this invention. 

L 5r^/\ig. 9 represents a block diagram of the Connecton Kernel. For 
simplicity/ we have only represented a connecton ensemble with its executive 
and with \ust one connecton in Fig. 9. The information about channels is only 
depicted for connecton C. The main difference between the abstract description 
of ensembles\ and the actual implementation is that connectons keep their own 
channel information. This option is more efficient and can become easier to 
implement in parallel /distributed computers. 

Each connefcton or connecton ensemble has a reference to the ensemble 
within which it belongs. This reference, however, is nil if the connecton is 
the topmost one. The\ ensemble connecton also has a reference to its executive. 
Additional variables \are currently used to manage the link information: 
ext Channels is an association list where each entry has the format 
grate ( {connecton\gate 1 , fF±lter lt rFilterJ , 
( connecton 2 , gate 2 , fFilter 2 , rFilter 2 ) , 

(connecton nl gafce n YFiIter n , rFilter D ) ) 



where gatej is an input gate if \connecton i is not the network, and is a 
network output gate otherwise. The Variable intChannel is associated with the 
30 network and defines all the channels ^starting at the network input gates. The 
two variables are defined for implementation convenience: revExt Channels and 
revlnt Channels. The reverse channels ara maintained to make the operation of 
removing connectons in run-time, faster. Inhere is a reverse channel for each 
(direct) channel in the model. 
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Each entry in the list represents a channel connecting two gates. A gate 
can have several channels to different gates. There is no constraint on the 
number of channels from a gate, or into a gate. For each channel there are two 
filters: direct (forward) and reverse filters. 

XVI. Message Table 

Channels among connectons are stored in a message table. A message table 
has one entry for each gate, and associated with each gate can be an arbitrary 
number of channels. 

10* V°l^7 \ariables extLinks and intLinks are instances of class MessageTable , 
Lements a mapping table for messages. Each message is an instance of 
class SCM&esage and is defined by 6 variables: 

m_senaer t the connecton that sends the message 
m_receiv^er f the connecton that will receive the message; 
15 /n_selector\ the message name; 

m^arguments , uhe message arguments; 

f Filters, channeNL direct (forward) filter; and 

r Filters, channel Veverse filter. 

20 The SCMessage method value \s defined by 
value 

m_receiver _sender: m_sendei 

(f Filter = Identity) & (rFil^er = Identity) if True: ["No filters" 
"m_receiver _perform: m_serector withArguments : m_arguments 

25 ] . 

"Only one argument signals are implemented" 
"Apply filters" 

A rFilter value: (m_receiver _; perform\ m_selector withArguments: 
(Array with: (f Filter value: (^arguments at: 1)) 

30 

Each channel can have two filters: forward (direct) and reverse 
represented by variables f Filter and rFilter, respectively. These filters 
transform the values sent to a gate, and the values returned from a gate, 
respectively. Filters are an effective solution to couple gates with different 
35 signatures without the creation of additional connectons to make the 
adaptation. If no filter is set, a default filter called the Identity is used. 
The Identity class method value: just returns the input value, and is defined 
by . 
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! Identity class method I 

value: aValue "Implements the identity function filter" 

"aValue . 

5 EXAMPLE 

We describe a connecton that sends and accepts values in Km that need to 
be linked with connectons that work in Meters and Miles. The structure of the 
connecton is given by the method 

connectonStructure 

10 |t | 

t := super connectonStructure. "The parent returns the empty structure" 
t add: #Km model: VelocityKm. "Km connecton" 

t add: #M model: VelocityM. "Meters connecton" 

t add: #Mi model: VelocityMi. "Miles connecton" 

15 t link: #Km gate: #out to: #M gate: #in: filter: 

[:x| x*1000] filter: [:x| x/1000] . 
t link: #Km gate:#out to: #Mi gate:#in: filter: 

[:x| x/1.65] filter: [x | x*1.65]. 

20 Links are established by the method link: gate: to: gate: filter: filter: , where 



he first filter is the direct filter and the second is the reverse filter. The 
direct filters convert Km into meters and miles and the reverse filters makes 
the reverse conversions. Filters permit to join gates with different 
interfaces without additional elements. Channel filters can be combined with 
25 gate output functions. For example the output function of gate out: could sum 
I*. all the input values in Km from connectons #M and #Mi. 

In the current implementation only one argument signals can have direct 
and reverse filters. The reason is the complex Smalltalk syntax necessary to 
IT. handle general number of arguments. In this case filter functions would become 

i"k 30 difficult to read. 

xvii. Message Breaking 

A? /The\ current implementation keeps the information about channels 
-dist/ributedl in the out variable of each connecton so the executive is only 
35 invoked to handle changes in the structure (i.e., message breaking). This 
design, although it implements conceptually the role of the executive, might 
prove more efficient in distributed applications. Additionally, caching 
systems can also\be become easier to implement. When the number of channels is 
very large, a ceVtral store implementation would need a hashing system to 
40 handle messages efficiently. Thus distributing channel information is an 
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/effective way to avoid hashing. In static structure networks, the message 

doe sNocDnder stand: is not strictly necessary if some pre-processing is done 

before compilation, replacing calls to variable out with a defined message. In 

this ca&e the exception mechanism would not be necessary and the 

5 implement aMon becomes faster. So the breaking process could be implemented as 

a pre-processor by those skilled in the art. The actual code of the message 

doesNotUnderstand: implemented in Smalltalk MT is as follows 

!ConnectonOutput\05:24 - 10/04/971 
does Not Under standi, aMessage 

10 |ms selector filter | 

selector := aMessage at: 2. "selector" 
ms := extLinks at\: selector if None: nil. 

ms isNil if True: flself error: 'Gate: ' , selector asSt ring, ' does not exist.'], 
filter := filters at: selector if None: nil. 
15 A self Jbroadcast: ms arguments: (aMessage at: 3) filter: filter.!! 

As shown, aMessage is a 3 -element array described by: [receiver, 
f'*% messageName, arguments] . This method acts as a message breaker that divides a 

\& message into the receiver, the selector (message name), and the arguments. The 

*' 1 20 reader should note that Smalltalk is one of the few languages where this 



tLi 



breaking mechanism is so easy to use, in spite that the original intention was 

exception handling. 

The call Jbroadcast: aMessage arguments: arguments filter: aFilter, 

broadcasts messages to all connectons linked to a gate. The last argument 

p=£ 25 represents the gate output function. This function is used to handle the set 

of input values to a gate. The method _broastcast : arguments : filter : is defined 

['^ in class Output, a parent class of ConnectonOutput and NetworkOutput classes, 

13 and is given by 

iOutput 09:04 -10/04/97! 
30 broastcast: nMes sages arguments: anArray filter: filter 

I ret I 

filter is Nil if True: [ 
| value | 

"Default behavior: no filter is defined at the output gate" 
35 (nMessages size = 0) if True: [ A nil] . 

"if there are no charnels returns nil" 

ret := nil. 

nMessages do: [:m| 

value := self _send: m arguments: anArray. 
40 (value = DeletedChannel) if False: [ret := value] . 

] . 

A ret "Returns the last value" 

] 
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ifFalse: [ 

|value| "A filter is defined" 
ret := OrderedCollection new. 
nMessages do: [:m| 
5 value := self _send: m arguments: anArray. 

(value = DeletedChannel) "The channel has been deleted, ignore it" 
ifFalse: [ret add: value] . "Collects all input values" 

] . 

-^filter value: ret. "Applies the filter to the input list" 

10 ] M 



There is a default behavior in the absence of filters. If an output gate 

has no filter assigned, the method returns the last value received, or the 

value nil if the output gate has no channels. When a filter is defined, a list 

15 of input values is collected and the filter is applied to this list to compute 

the return value. The default behavior was chosen for it seems to be used in 

most of the situations. The call _send: a SCMessage arguments: anArray, sends 

a signal to linked connectons, and is defined by 

lOutput 09:04-10/04/971 
20 send: aSCMMessage arguments: anArray 

| receiver | 

aSCMessage isNil if True: [^DeletedChannel] . "The channel has been deleted" 
aSCMessage arguments: anArray. 
receiver := aSCMessage receiver. 
25 "Send signal to the connecton" 

(receiver -= networkOutput ) if True: [^aSCMessage value] . 
"Send signal to external connections" 

""receiver extMesssage: aSCMessage arguments : anArray. I ! 



J cor 



^ ^hiX method makes the separation between signals that are sent to 



connectons mside the network, and signals that are sent to connectons outside 
the network. Vn the later case, gate names are translated using the link 



information of \he parent network. 
Cj^V/} ^^^^e call _extMessage: aSCMessage arguments: anArray is defined in the 
35 network oVtput to access connectons outside the network, and is defined by 



INetworkOuCout 09 :04r 10/04/97 ! 
extMes sage \aSCMes sage arguments: anArray 

|ms selector f ilter | 
selector : = iaSCMessage selector. 
4 0 ms : = extLinks at: selector. 

ms isNil ifTrut: [self error: ' Port : 1 , selector asString, 'does not exist.']. 

filter := filteVs at: selector if None: nil. 

""self Jbroadcast^ ms arguments: anArray filter: filter!! 
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tworks also need to break messages. Although messages coming from a 
connecton within a network can be easily sent to the output directly, because 
they are Nalready broken, messages arriving to the network from the outside 
must also he identified for they can come from a standard calling mechanism, 
5 that is, the\message 

connect oil message 

must work wheneveit connecton represents a basic connecton or the connecton is 

an ensemble. The message breaker in the network is defined by 

INetworkOutput . CALLBACK methods 09:04-10/04/97! 
10 doe sNot Under st and: aMegsage 

|ms selector filter | 

selector := aMessage at: 2. "selector" 
ms := intLinks at: selector if None: nil. 

ms isNil ifTrue: [self eroror: 'Gate: selector asString, 'does not exist']. 
15 . filter := inFilters at: selector if None: nil. 

"self broadcast: ms arguments: (aMessage at: 3) filter: filter.!! 



the network is an inner model and it is not accessed by regular 

messages, \ signals are transmitted by the method _perfonn:withArguments : 

20 defined by 

INetworkOutpVit 09:04-10/04/97! 
_perform: selector withArguments : arguments 

|ms filter I 

ms := intLink>3 at selector if None: nil. 
25 ms isNil ifTrufe: [self error . 'Gate: 1 , selector asString, 'does no exist 1 ], 

filter := inFil\ers at: selector if None: nil. 
A self Jbroadcast\ms arguments: arguments filter: filter.!! 

Message broadcast is done by the method already described before because 
30 both ConnectonOutput and NetworkOutput are subclasses of class output. 



XVIII. Support for Structural Changes 

The following methods were defined in the Desmos System to change the 
connecton structure during the execution of a program: 
35 addConnecton: aConnecton name: aName, adds a new connecton aConnecton, 

with an identifier aName; 

link: aName gate: aGate to: bName gate: bOate filter: dFilter filter: 
rFilter, links aConnecton named aName gate aGate to gate bGate of connecton 
bName, establishing direct filter dFilter and reverse filter rFilter; 
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link: aName gate: aOate to: bName gate: bGate, links aConnecton named 
aName gate aGate to gate bGate of connecton bName, direct and reverse filters 
are assumed to be the identity function; 

removeConnecton: aName, removes the connecton named aName and all its 
channels ; 

replaceConnecton: aName with: b Connecton name: bName, replaces a 
connecton named aName with connecton a named bName; 

unLink: aName gate: aOate from: bName gate: bGate, unlinks aConnecton 
named aName gate aGate from gate bGate of connecton bName; 

unLink: aName gate: aGate, deletes all the links starting at aGate of 
connecton named aName. 

A connecton is referenced by a name and not by a pointer. Connecton 
names are assigned, to connector instances in the connecton structure 
definition. 

XIX. Structural Inheritance 

New connectons are seldom built from scratch. Instead they are usually 
built using an existing connecton class as a template. A new class is defined 
just by incorporating all common features of the existing class and by the 
addition of some new characteristics (methods and state variables) . 
Inheritance provides not only an effective means for code reuse but also a 
mechanism for grouping related models in a taxonomic hierarchy. Structural 
inheritance is an effective way to build new connectons from existing ones. 
Support for reusing structural objects is given by inheritance of structure in 
a similar way to code reuse in conventional inheritance. 

A connecton name is just an alias that can be used to define the network 
structure. Each connecton name is associated to a connecton class. To build a 
connecton, names in the structure definition are replaced by an instance of a 
connecton class. The network structure is thus a template, and actual networks 
are obtained by replacing aliases by instances. In the Deshos environment (as 
the illustrative embodiment of the inventive connecton paradigm disclosed 
herein), the following operations are defined over the structure of a network: 

addConnecton: aName, class: aClass, adds a new connecton of class, 
aClass, to the network structure; 

removeConnecton: aName, removes a connecton from the network structure; 
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replaceConnecton : aName byClass: aClass, replaces the class associated 
with aName by aClass; 

link: aName gate: aOate to: bName gate: bQate filter: dPilter filter: 
rFilter, creates a link and filters between two connectons; 

link: aName gate: aGate to: bName gate: bQate filter: dFilter filter: 
rFilter, creates a link between two connectons; 

unlink: aName gate: aGate from: bName gate: BGate, deletes a link 
between two connectons; 

unlink: aConnecton gate: aGate r deletes all the links from aGate of 
aConnecton . 



In the Desmos system connecton models are hierarchically organized. 
Connecton is the root class for all connecton classes. The class 
ConnectonExecutive is the superclass of all network executives. This class 
implements all basic operations that support changes in connecton network 
structure. These operations include adding and deleting connectons and links. 
Every specific domain connecton network must be a subclass of the class 
ConnectonExecutive . 

Fig. 10 represents a partial view of the Desmos hierarchy, as described 
above. All the subclasses of the class ConnectonExecutive can inherit the 
structure of the parent class. The ConnectonExecutive class provides just an 
empty connecton network. 

' Structural inheritance can be used for several purposes. For example, a 



superclass^ can be used to provide the common structure to its subclasses. 
These subclasses therefore must only just add the structural differences. We 
illustrate th\ use of inheritance to create a NOR4 gate from an OR4 gate (Fig. 
9) . The OR4 gate\. (represented in Fig. 11), is a 4 input gate and is a network 
made of 3 basic tWo input OR gates. The definition of the OR4 class in given 
Fig. 12, where the\def inition of the network is made within the connecton 
Structure method. 

the OR4 class we can easily derive the NOR4 class depicted in Fig. 
13. The \Desmos definition is given in Fig. 14, where the method 
connectons time ture only needs to define the differences from the initial OR4 
gate. The fAst line obtains the structure of the parent class. The second 
line- adds a model named #NOT of class NOT. Actual instances are obtained by 
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rfeplacing aliases by class instances, that is #NOT is replaced by an instance 
of connecton class NOT named #NOT. 

XX. The MVC Architecture and the Dependency Mechanism 

We now describe how the Smalltalk MVC framework can be implemented using 

5 conneotons, see S. Lewis. The Art and Science of Smalltalk, Prentice Hall, 

1995. We\use a simple graphical system represented in Fig. 15, which displays 

the speed \f a car. The transducer connecton converts the throttle aperture to 

a value of Velocity, and this value is sent to the output gate speed:. The 

transducer operates independently of the connectons linked to its output. In 

10 the system of Vig. 16, two graphical widgets that display the value of the 

velocity and position have been added. A plot chart has been added and linked 

through the establishment of a new channel between the gate speed: of the 

transducer and the Vnput gate sample:. An XY-Plot was also added to draw car 

position over time. Vhe input gate x:y: of the XY-Plot chart is linked from 

15 the output gate x:y: ot the transducer. The aperture: action of the transducer 

./I is defined by 

jj'J; aperture: aValue 

| speed position | 

speed := self computeSpeed: aValue. 
20 position := self computeSpeed: aValue. 

out speed: speed. 

out x: (position x) y: (position y) . 



i -if- 



St}' 



A solution using the Smalltalk dependency mechanism cannot discriminate 
25 messages for it uses the same update: message to update the list of all the 
dependents. Thus all the objects will receive an update even if the message is 
not directed to them. Another Smalltalk limitation exists when new messages 
are created for in many cases existing objects need to be modified to 
understand new update message parameters. The unstructured dependency 
30 mechanism of Smalltalk was replaced by the structured concepts of gate and 
channels in the connecton approach of the present invention. In this example, 
the advantages of the connecton programming are evident . 

XXI. Connectons vs. Objects 

35 The object paradigm relies on absolute method and instance addresses. 

The typical message sending consists of a name of an object followed by the 
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name of the method and some arguments. If a widget displays a number on a 

window, the command to change the information would have the following format: 

abridge t display: aNumber. 
aPicture x: newX y: newY, 

Although clear, this process of communication between objects has two 
main constraints to obtaining reuse. First, aWidget is typically a reference 
to an existing object. Second, display: is a message that the object can 
understand. To be truly reusable, objects should not rely on this specific 
information. The absolute address does not allow the object to be used with a 
new kind of widget that to show a number uses a method named show: instead of 
display: . A straightforward solution to solve the first problem is the use of 
an indirect reference. In this case, the variable aWidget could be 
instantiated after the creation of a specific widget object. However, this 
solution does not solve the problem of a possible different method name in the 
outside object. This simple solution has also another problem: it does not 
allow that the same message may be sent to an unknown number of other objects. 

Connectons overcome these problems by specifying the outside world 

through a reference to the pseudo variable out. Any messages that cannot be 

handled locally by the connecton are sent to the outer world in a general and 

simple way. The code to display a number using connectons would be 

out display: aNumber. 
out x: newX y: newY. 

As can be seen, the same message protocol is used to achieve different 
results. Both "displaying a number" and "moving a picture" are messages sent 
to outer connectons through the variable out. In consequence of the relative 
messages, names, actual widgets and pictures can have very different message 
names to handle the intended actions . The mapping between message names is 
handled by the linkage mechanism of connectons. Messages are ignored if the 
outside world does not exist. Moreover, the number of connectons linked to a 
gate is arbitrary. The current mechanism returns nil as a default value of a 
message sent to several connectons. When a message is sent to just one 
connecton, the current implementation returns by default the value sent by 
that connecton. Connectons provide a simple way to monitor variables. The 
explicit mechanism to monitor variables is less prone to error than the 
standard mechanism of active values or daemons. 
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The Desmos language, illustrating the connecton paradigm disclosed 
herein, can use all original Smalltalk libraries because it may also use the 
standard message protocol. Objects can be seen as connec tons with input gates 
and no output gates. Objects, thus, can be used as terminal connectons. 
5 This flexibility achieved by connectons involves, however, a higher 

computational cost, mainly to translate output gates to input gates. 
Connecton- oriented programming can make effective use of a CASE tool where 
connections among connectons can be graphically depicted and edited. The 
translation between such a CASE tool and the actual code would be 
10 straightforward to those skilled in the art. Also, the realization of a 
library of connectons will be very simple to achieve due to connecton 
encapsulation . 

XXII. Connectons vs. Hardware 

15 Traditional hardware has been referred to herein as having a high 

quality standard, which is lacking in traditional software. The connecton 
paradigm of this invention, however, not only approaches the high hardware 
quality standard, but also can be clearly shown to overcome it. The first 
feature is hierarchy, while hardware is modular, it cannot implement 

20 hierarchical concepts. The second feature is that compared with hardware, the 
connecton structure is dynamic by design. Connectons can change composition 
and channels at run-time. Hardware is not typically automatically 
reconf igurable . 



25 XXIII. Connectons vs. Patterns 

show the power of the Connecton paradigm, we now describe an example 
taken f^rpm the software design pattern approach and compare it with the 
corresponding Connecton solution. Most of the so called structural patterns 
described \in, E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design 
30 Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. 
and remarkably, some of the behavior patterns can be replaced by connectons 
without the introduction of additional elements, or a simplification of the 
problem. The Chain of Responsibility pattern, categorized as a behavioral 
pattern, is a fVamework to pass commands through a chain of objects. Each 
35 object in the cha\n has two possibilities: to accept the command or to pass it 
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td the Viext element in the chain if the command cannot be locally handled. 
Each patVern is based upon a set of special purpose classes . The connecton 
solution, Vlepicted in Fig. 17, does not demand any special model to handle 
chains. A qhain is just a special topology, that is, a chain is just a 
5 . specific problem of Connecton composition. 

Most of the structural patterns can be described by an ad hoc 
composition and do not represent a general purpose solution. Some of the 
patterns described in, see E. Gamma, R. Helm, R. Johnson, and J. Vlissides. 
Design Patterns: Elements of Reusable Object-Oriented Software. Addison- 

10 Wesley, 1995, treated as independent, are in reality seen as the same in the 
Connecton paradigm. Examples are the patterns Composite and Facade that in the 
Connecton paradigm only present different topologies. Patterns seems thus to 
lead to an arbitrary taxonomy. 

We describe now in mode detail the Connecton solution for the Chain of 

15 Responsibility problem. Each connecton in the chain can be described by 
in: aMessage 

self respondsTo: aMessage if False: ["out out: aMessage] . 
A self accepts: aMessage 

20 Messages that cannot be handled locally are just sent to the outside. 

The actual code that will be invoked depends on the existing links, or in 
other words, it depends on the existing specific structure. 

Solutions categorized by the class -subclass relationship do not show any 
fundamental characteristic of the problems. Because traditional solutions 

25 based on Objects fail miserably to represent structure, one is forced to find 
specific solutions to every problem that demands for a structural 
representation. Because structure has shown to be an evasive issue, different 
solutions are commonly obtained for problems that appear to be different only 
because the structural perspective is not considered. Thus, significant 

30 programming effort is wasted because today's paradigms fail to represent 
structure. 

XXIV. Analysis and Design 

Traditional software engineering approaches divide the development of 
35 new information systems in 4 large phases: analysis, design, implementation 
and testing. Connectons can have a strong impact on these traditional phases 
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for the first three are all done simultaneously. Analysis can be broadly 
defined as the specification of the problem and the identification of sets of 
inputs and outputs to the system. Design is usually referred as the process of 
translate the analysis specifications into programming modules/ and 
5 implementation is the result of translating design into a computer language. 
These three phases are independent, so each phase produces some document to 
the next stage. The major drawback of this approach is that it is difficult to 
enforce the integration between these phases, and for example, there is not a 
mechanism to ensure that design has fulfilled all the analysis requirements. 
10 With connectons, analysis design and implementation are all done using 

the same tools. Analysis and design are actually the same procedure. At the 
end of the analysis phase, a set of hierarchical connectons and their 
interconnections is defined. That is, and surprisingly, the implementation 
model is almost finished. To complete the actual implementation, only basic 
15 connectons that are not yet defined in some connecton library need to be 
developed. Thus the Connecton paradigm represents a major breakthrough in 
software engineering. 

A repository of connectons is the kernel of connectware reuse, and by 
economical reasons, it will constrain the software construction process. Like 



p 

; 4 20 an architect that chooses standard height and width for doors and windows, 

m 

connectware architects must utilize, where possible, existing connectons. 
13 Thus, analysis and design are constrained by existing connectons. 

: The test on connectons seems only to exist in the bottom up manner, and 

s 

^ top-down testing seems to have no definition, for on the top there are only 

• 25 connections and no actual code. Thus it seems that test must be done 
hierarchically, from basic connectons to network connectons. Because 
connectons provide a modular approach, connectons can be tested independently. 
Special testing methodologies must be developed to access the correctness of 
dynamic structure connectons. 



30 



XXV. Implementation Aspects 

While the connecton paradigm was described herein with respect to the 
Desmos system, various other implementations (not limited to Smalltalk) of the 
connecton paradigm may be utilized in various systems. 
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For example, the current implementation of the Desmos system runs in one 
single processor computer and with one single thread of control. Connectons, 
however, may also be located in different processes, in different processors 
and even within different computers. The nature of the connecton programming 
does not change, only links must be completed with the physical location of 
the connectons. This location can include the process identifier, the 
processor identifier and the machine identifier. For example, if two 
connectons are located in different computers connected through the Internet, 
location must include the IP of the computers. Please note that in the 
implementation defined and described herein, this information is not necessary 
because all the connectons are in the same location. 

More particularly, the current implementation runs in a single thread of 
control. Multiple threads and multiple active connectons can be easily 
accommodated. Concomitantly, traditional methods for control of access to 
shared memory, e.g., semaphores and critical sections may be employed. While 
the described embodiment is synchronous, an asynchronous design may be easily 
implemented in a multithreaded version by those skilled in the art. 

Furthermore, the current implementation requires that the connectons be 
created from their models (classes) before use. Providing connectons with a 
persistent storage mechanism would allow connectons to be stored and loaded 
into memory without creation from scratch utilizing their class description. 
Persistency is a technique currently used for storing objects in databases. 
And as stated above, links may be stored in the network executive or may be 
distributed among connectons (based on efficiency) . 

The message breaking mechanism described above is dependent upon the 
Smalltalk dialect used for implementing the connecton system. Other Smalltalk 
dialects have their own specificity for message breaking. In the Desmos 
implementation described herein, the message breaking mechanism was 
implemented using the error handling mechanism of Smalltalk MT, see Smalltalk 
MT User's Guide. Object Connect, 1995. No other languages are known to 
provide these primitives to implement the message breaking mechanism 
described. However, it should be apparent to those skilled in the art how to 
incorporate the basic mechanisms for eliminating absolute object /methods 
addresses in the compilers of any of the multitude of existing computer 
languages. That is, although the mechanisms may be different from those 
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employed in the Smalltalk language, the connecton paradigm is not limited 
thereto. 

If the operating system needs to change the physical location of a 
connecton, ex. : for load balancing purposes, only links need be updated by the 
operating system. The connecton structure should remain the same and no 
connecton should be re -programmed. Thus, operating system procedures, like 
load balancing procedures, do not change the nature of this invention. The 
several methods described may be merged, and an implementation that utilizes 
one or a group of the previous characteristics can be easily developed. For 
example, the multithreading version of the connecton paradigm can be 
constructed into a system that runs on several microprocessor computers linked 
by a computer network. 

Also, some technical difficulties must be solved, for connecton based 
languages demand capabilities not usually found in the most common compilers. 
Although static structure connectons can be implemented efficiently by simple 
changes in current compilers, dynamic structure connectons will demand better 
support of compilers. If the ability of dynamic structure software is not 
used, current compiler technology can produce Connecton code as efficient as 
Object code. In this case, hierarchical models could be flattened, that is, 
the hierarchy is removed, and all channels can be replaced by actual message 
calls. Multiple channels starting at the same gate could be replaced by an 
iteration by the compiler. With this simplification, Connectons could be 
easily incorporated into current compiler technology. This is easily 
accomplished by those skilled in the art. In this case the out variable 
mechanism would have a simpler implementation than those described for the 
Desmos system, that involves the Smalltalk error handling mechanism. 

Dynamic structure does not permit the removal of the hierarchy, and 
caching connectons and channels may prove a good solution to improve 
efficiency. Caching would avoid the repetition of the actions necessary to 
find all the components connected to a gate. This information could be kept 
and updated when a change in structure occurs. 

In the Desmos systems links and Connectons gates are specified directly 
in the programming language. However, the implementation of a graphical 
interface, like for example a CASE tool, to help defining connectons will be 
easily accomplished by those skilled in the art. 



-35- 



eg\f:\1371\13137\SPEC\ 13137. JFV 



The present implementation of Connectons is currently stored in a 
computer hard disk and is loaded into computer RAM in order to run. Other 
forms for storing an implementation of connectons, like CDROM, DVD, floppy- 
disk, or magnetic tape could also be used. A connecton implementation can also 
be stored and run from PROM, EPROM, EE PROM or any other computer memory 
technology. 

XXVI. Conclusions 

In conclusion, traditional objects describe only terminal connectons and 
thus are not fully reusable. Connecton reusability is achieved by removing all 
absolute addresses from connecton definition and by viewing software units as 
structural entities. Connectons, therefore provide full support for software 
reusability. Under the Connecton paradigm, software is built in a hierarchical 
and modular form. Connectons are thus suitable for building large software 
systems that can be easily reused. The Connecton paradigm scales well and it 
can be used in the implementation of systems, ranging from the most simple to 
the most complex. 

Connectons are a paradigm shift for software engineering for they 
encompass a new way for building software by the use of independent and 
reusable software units. Connectons will obviously have a strong impact on the 
way software is made. The process development cycle will be completely changed 
by the existence of a connecton repository that will influence all phases of 
software life cycle. This cycle will be constrained by economical factors and 
existing connectons will be used when possible, and impose strong constraints 
to the analysis in the same way that standard doors and windows constrain the 
project of a house. 

Connectons, because of their simplicity, open the door of software reuse 
to everyone, for its use does not need any special skills or expertise. Thus 
small and large software houses and individual programmers can turn their 
software work into reusable Connectonware just by using connecton programming. 

The reader should note that legacy is the major enemy of any new 
software paradigm. Work needs to be done to make existing software compatible 
with the new connectonware. Nevertheless, current objects are compatible with 
connectons and can be used not only to implement the state of connectons but 
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can also be used as terminal connectons. Another possibility is to wrap 
current objects inside connectons. 

Finally, dynamic structure models as taught herein open a gate to the 
dynamic update of software systems. Because Connectons can be dynamically 
5 configured, one can easily foresee a scenario where software can be upgraded 
by changing some of the connectons that become obsolete. This is especially 
important in running non-stop systems, like real-time systems, where this task 
would have a large economical impact. 

The many features and advantages of the present invention are apparent 

10 from the detailed description, and thus, it is intended by the appended claims 
to cover all such features and advantages of the invention which fall within 
the true scope and spirit of same. Moreover, since numerous modifications will 
readily occur to those skilled in the art, it is not desired that the present 
invention be limited to the exact construction and operation illustrated and 

15 described herein and accordingly. All the suitable modifications that are 
equivalent are intended to fall within the scope of the claims. 
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